歷經了一個月的煎熬，好不容易在昨天把 websocket server 部署到 heroku，剩下最後的 client 頁面放到 github pages。遊戲就可以給大家玩了對嗎？不，其實還有很多議題，不僅僅只是遊戲完成度不高的問題。今天我們就把上線前還要考慮/處理的部分也一併討論一遍吧

先說一下 client 頁面確實已經放到github 上了，裡面的 ws 網址也確實換成 heroku 的主機網址了。但遊戲卻又打不開了，一看 devTool 記錄才發現一串紅紅的錯誤 (fig.1)，原來是因為在 https 中沒辦法使用 ws:// 協定，必須要使用 wss://

所以我們接下來就來談談關於 websocket 的安全問題吧

配置 WSS

根據 heroku 這篇官方文章，我們可以知道 wss:// 是必要的協定。而在 heroku 上面設定 HTTPS 相關的知識都在這個分類 中找到。

HTTPS 大至分成手動配置和自動配置，手動配置透過 heroku SSL，自動配置透過 ACM (Automated Certificate Management)。

身份識別機制

這邊引述一下官方文件給的建議，這是實現身份認證比較簡單的方式，大家可以參考一下

So, one pattern we’ve seen that seems to solve the WebSocket authentication problem well is a “ticket”-based authentication system. Broadly speaking, it works like this:

• When the client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization “ticket”.
  當用戶端代碼決定打開 WebSocket 時，它會聯繫 HTTP 伺服器以獲取授權“票證”。

• The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other sort of internal record keeping you might need.
  伺服器生成此票證。它通常包含某種使用者/帳戶 ID、請求票證的用戶端的 IP、時間戳以及您可能需要的任何其他類型的內部記錄保存。

• The server stores this ticket (i.e. in a database or cache), and also returns it to the client.
  伺服器將此票證存儲（即存儲在資料庫或緩存中），並將其返回給用戶端。

• The client opens the WebSocket connection, and sends along this “ticket” as part of an initial handshake.
  客戶端打開 WebSocket 連接，併發送此「票證」作為初始握手的一部分。

• The server can then compare this ticket, check source IPs, verify that the ticket hasn’t been re-used and hasn’t expired, and do any other sort of permission checking. If all goes well, the WebSocket connection is now verified.
  然後，伺服器可以比較此票證，檢查源IP，驗證票證是否未被重複使用且未過期，並執行任何其他類型的許可權檢查。如果一切順利，現在將驗證 WebSocket 連接。

今天大概講一下部署要注意的事項，我們明天見。